2022-12-23 Stolperfalle ULA-Präfix unter Windows

NPTv6 / IPv6 bevorzugt / fd00::/8

Ein Client mit Dual-Stack bevorzugt beim Verbindungsaufbau, bei vorhandensein eines AAAA-DNS-Eintrags in der Serveradresse, IPv6. Kann die Verbindung nicht aufgebaut werden, wird es nochmal mit IPv4 versucht. Anders verhält sich der Windows-IP-Stack, wenn das Default-GW nur per ⎇ULAs (Unique Local Addresses) erreichbar ist. Dann wird IPv4 bevorzugt und nur auf IPv6 zurückgegriffen wenn ausschließlich ein AAAA-Eintrag vorhanden ist bzw. direkt mit Adressen gearbeitet wird. (Zum Vergleich, OpenBSD interessiert das nicht und bevorzugt weiterhin IPv6.)
Die Überlegung dahinter wird vermutlich sein, das private ULAs nicht im Internet geroutet werden dürfen und daher die Wahrscheinlichkeit über so ein Gateway irgendwohin zu kommen kaum gegeben ist. Nun gibt es aber ⎇NPTv6 also IPv6-to-IPv6 Network Prefix Translation, was Gateways/Routern ermöglicht die Präfixe zu übertragen und damit den Hosts doch einen Weg ins Internet zu bieten.

Damit Windows auch in einem ULA-Netz IPv6 bevorzugt, muss eine entsprechende Regel für fd00::/8 erzeugt werden. Dazu folgendes mit erweiterten Rechten ausführen:
netsh interface ipv6 show prefixpolicies
netsh interface ipv6 add prefixpolicy fd00::/8 3 1
### Bitte vor dem blinden Kopieren prüfen ob die Werte mit der Ausgabe von show prefixpolicies übereinstimmen. Könnte ja sein Microsoft hat die Standardwerte irgendwann geändert. ###
netsh interface ipv6 set prefixpolicy ::1/128 50 0
netsh interface ipv6 set prefixpolicy ::/0 40 1
netsh interface ipv6 set prefixpolicy ::ffff:0:0/96 35 4
netsh interface ipv6 set prefixpolicy 2002::/16 30 2
netsh interface ipv6 set prefixpolicy 2001::/32 5 5
netsh interface ipv6 set prefixpolicy fc00::/7 3 13
netsh interface ipv6 set prefixpolicy fec0::/10 1 11
netsh interface ipv6 set prefixpolicy 3ffe::/16 1 12
netsh interface ipv6 set prefixpolicy ::/96 1 3
netsh interface ipv6 show prefixpolicies


Was es mit dem "add prefixpolicy fd00::/8 3 1" auf sich hat erklärt Ross Tajvar in dieser ⎇StockExchange Antwort sehr gut.

Der set-Befehl für die bereits vorhandenen Regeln ist leider nötig, weil andernfalls, nach einem Neustart, nur noch die per add hinzugefügte Regel vorhanden wäre. Dies gilt lustigerweise aber nur für das allererste Mal. Fügt man nach einem Neustart per add weitere Regeln hinzu, kann man sich das set der vorhanden sparen. ¯\_(ツ)_/¯ Microsoft

Warum eigentlich fd00::/8, wenn die Unique Local IPv6 Unicast Addresses als fc00::/7 definiert sind und eine oberflächliche Suche nach fd00 in⎇RFC 4193 keine Treffer bringt?

Das achte Bit entscheide darüber ob die Local Unicast Adresse tatsächlich lokal lokal ist. :-) Siehe RFC-Text.
Hex FC + 1 = FD

Siehe auch:
⍈Stolperfalle bei NPTv6

⍈Homepage